Application Load Balancer起動直後のENIを観察してみた

いわさです。

Application Load Balancer(ALB)はAWSでWebシステムを構築する上ではよく利用するサービスだと思います。
先日CloudFormationでALBとEC2を同時に作成した際に想定してなかった挙動をしたので少し観察してみました。

何か得られるものがあったわけではなく、「へー、こんな動きしてるんだー」くらいです。

観察のきっかけ：ヘルスチェックのソースIPアドレスが想定していたより多かった

以下のようにパブリックサブネットにALBを配置し、ターゲットグループにEC2インスタンスが直接ぶらさがる構成です。

EC2にはApacheをインストールし、AZは片側１台のみです。
Webサーバーへのアクセスログを確認するためにCloudWatch Logsへ取り敢えず出力しています。
ヘルスチェックの間隔は10秒です。

ALBを配置するパブリックサブネットは 10.0.0.0/24 と 10.0.1.0/24 で２つのAZに用意しています。

テンプレートはこちら

起動後数分のログは以下のようになっています。

起動後直後は１台(10.0.0.19)からのみヘルスチェックリクエストが送信されています。
そして、１分半たつともう１台（10.0.1.124）からもリクエストが送信されました。

なるほど、両AZのALBからヘルスチェックが開始されるまでタイムラグがあるのですね。
と思っていたら、それから更に30秒後に今度は新たなもう１台（10.0.0.206）から送信され始めました。１台目と同じサブネットですね。

ここから10分以上3台からヘルスチェックが送信され続け、その後一番最初にヘルスチェックを開始したENIからのリクエストが送信されなくなります。

ALB作成時のENIは３つ作成されたり４つ作成されたりすることがある

2つのパターン（想定どおりのパターン）

EC2をap-northeast-1aのサブネットにデプロイするよう指定していたとして、ALBデプロイで自動作成される最初のENIが別AZ(ap-northeast-1c)の場合に発生するようです。

あとはこの２つのENIでヘルスチェックしつづけ、直近でのENIの増加はありませんでした。

3つのパターン

何度か作ったり壊したりしているうちに、3つ作成される時のパターンはわかりました。
CloudFormationでALBとEC2を同時に作成して、ALBの１つ目のENIとEC2のAZが同じだった場合は一時的にENIが3つになるようです。

EC2をap-northeast-1aのサブネットにデプロイするよう指定していたとして、ALBデプロイで自動作成される最初のENIが同一AZの場合に発生するようです。

1つ目のENIにパブリックIPアドレスが割り当てられて、ステータスがIn-useになったのち、ap-northeast-1cでENIの作成が始まります。
その作成中にap-northeast-1aでも追加のENIの作成が始まります。

この時点ではALBの名前解決で取得されるIPアドレスは１つ目のもののみでした。

iwasa.takahito@hoge~ % nslookup hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com
Server:        192.168.111.1
Address:    192.168.111.1#53

Non-authoritative answer:
Name:    hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com
Address: 176.34.8.133

その後３つのENIにパブリックIPアドレスが割り当てられると以下のようになります。

iwasa.takahito@hoge ~ % nslookup hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com
Server:        192.168.111.1
Address:    192.168.111.1#53

Non-authoritative answer:
Name:    hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com
Address: 52.198.77.29
Name:    hoge-web-alb-260483299.ap-northeast-1.elb.amazonaws.com
Address: 52.197.130.184

１０分ほど経過すると、最初に追加したENIが削除されます。

4つのパターン

結局再現が出来なかったのですが、一度だけ４つのENIからヘルスチェックが送信されているパターンがありました。

想像ですが、上記の３つのタイミングでアクセスし４つ目が立ち上がったとか・・・ とはいえ、ページを１〜２回表示した程度なので負荷による可能性は低そうです。

このALB+EC2の作成と削除を10回近く行ったと思いますが、4つのパターンは1回のみでした。

1つのパターン

ちなみに、ターゲットグループにインスタンスが１台も紐付いていない場合はALBのENIは1つになります。
知らなかった。

インスタンスがターゲットグループにぶら下がると、ALBがENIを作成してヘルスチェックを開始するような仕組みになってるみたいですね。

自動でENIを生成するように制御できるのか

ENIを削除またはデタッチ

片方のAZのENIを削除もしくはデタッチすると、空いたAZでENIを自動生成してくれるかもと思い試してみました。

ALBからENIのデタッチは出来ませんでした。
強制デタッチも失敗しました。

デタッチ出来ないということで削除も出来ませんでした。

ヘルスチェックENIのひとつの通信を遮断した場合はどうなるのか

それぞれのAZのENIからヘルスチェックが送信されていましたよね。
もしかして成功/失敗のENIが混在していると、新しくENIを生成してくれたりするんじゃないかと思って試してみました。
ACLで対象IPアドレスをブロックしました。

ヘルスチェックステータスがUnHealthyにはなりましたが、ENIは自動生成されませんでした。

このあたりでENIが自動生成されるとパブリックIPアドレスを強制的に変えるなど出来ておもしろいかなと思ったのですが難しそうでした。

さいごに

これらの内容は知っている方は当然抑えられている仕様かもしれませんが、明確なドキュメントが見つからず、せっかくなので検証結果を載せてみました。
もしこれらの挙動の背景などご存知の方がいらっしゃればこっそり（@Tak1waまで）教えてください。